[Serverless Days Tokyo 2019] 無限のスケーリングと有限の失敗　サーバーレス回復力のレッスン

遅くなりましたが、10/22(火)に開催されたServerless Days Tokyo 2019のセッションレポートです。

登壇者

Microsoft Software Engineer Azure Functions

Katy Shimizu

レポート

• サーバーレスとは
  • サーバーの抽象化
  • イベント駆動型
  • 従量課金
• インフラストラクチャは顧客のために維持される
• データ→イベント→サードパーティAPI→イベント→Fuctions→ DB
  • サードパーティAPIとDBサーバが死ぬとどうなるか
  • 失敗は絶対に起こるため、アプリーションがそれらを処理する必要がある
• サーバーレス アプリケーションが失敗する場所
  • 依存関係
  • ソースコード
  • 外部依存関係
  • サーバーレス・Fassサービスの障害
  • IaasとかPaasサービスの障害
  • データセンターインフラの障害
• 失敗例
• レースコンディション
  • ネットワーク障害
  • レート制限
  • ハードウェア障害
• 障害に対処する方法
  • クラウドデザインパターンを用いることである程度軽減することが可能
• 設計パターン: 再試行する
  • 呼び出しが500で失敗したので再実行
  • もう一度500で失敗したので再実行
  • 200で終了
  • 再試行パターンをキュートリガーに追加する
• 特別な考慮事項
  • レート制限
  • エクスポーネンシャルバックオフ
  • タイムアウト
  • キューを使用
  • サイドエフェクト
  • アイデンポーテンシー
• 複雑なシナリオ
  • Manageable Sequencing ＋Error Handling/ Computing
  • Fancing-out & Fancng-in
  • External Events Correction
  • Flexible Automated Long-runnning Process Monitoring
  • Http-based Async Long runnning APIs
  • Human Interaction
• 設計パターン：サーキットブレーカ
  • 障害が発生するとアプリケーションは再試行を繰り返すが、アプリケーションは失敗がくり返されていることを検知して安全にエラーを処理する、復旧した場合に元に戻す
  • サーキットブレーカパターンを構築するのは困難

感想

英語でのセッションでしたので、スライドベースのレポートになってしまったんですが、サーバーレスの障害にキューを使った再試行パターンやサーキットブレーカパターンなどクラウドデザインパターンを用いて対処する方法について述べられてました。下記のようにAWSのクラウドデザインパターンのサイトがありますが、上記のパターンの他にもかなりの数のパターンがあるため、参考にしたいなと思いました。

http://aws.clouddesignpattern.org/index.php/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8